This invention relates to software program modules. More particularly, this invention relates to a method and system for categorizing failures of a program module for transmission to a repository for storage and analysis.
Despite the best efforts of software developers, software programs inevitably fail at one time or another. One type of failure is a crash. A crash occurs while a program module is running and results in the suspension of operation of the program module. Crashes are frustrating to users and, in some cases, may cause the user to lose work. Another type of software program failure is a set-up failure. Set-up failures occur during installation of a program module onto a user""s computer. Set-up failures may prevent certain aspects of the program module, or even the entire program module, from being installed on a user""s computer.
Crashes and set-up failures create a significant amount of work for product support personnel. Product support personnel, typically contacted via telephone, are often limited in their ability to diagnose problems due to the limited amount of information they can receive from the user. For example, the product support personnel may only know what the user was doing when the crash occurred or at what point of the installation the set-up failure occurred. There may be a significant amount of information on the user""s computer that may be useful to the product support personnel or to the software developers to diagnose the failures. However, because product support personnel and the software developers are not physically present at the user""s computer, this information can not be extracted and analyzed.
Thus, there is a need for a method and system for extracting from a computer relevant information regarding a failure of a program module, including the location of the failure, and transmitting this information to a software manufacturer so that the failure may be diagnosed and corrected. There is also a need for a method and system for requesting information from a failed program module, in addition to the location of the failure, and transmitting this additional information to a central repository for storage and analysis.
In developing such a method and system for reporting failures in a program module, there is a need for a method and system for categorizing failures to differentiate between separate failures. One way to differentiate between separate failures is to transmit and analyze massive amounts of data regarding a failure. However, sending massive amounts of data regarding a failure to a server is extremely inefficient and virtually impossible. For example, it is important that a lot of failure data not be transmitted to the server because many users will transmit the data via modems, etc. taking a lot of time to upload. Thus, there is a need for a method and system for categorizing failures using a minimal amount of uploadable data, while still differentiating between separate failures.
The present invention satisfies the above described needs by providing a method and system for categorizing failures of a program module.
In one aspect, the invention comprises a computer-implemented method and system for categorizing information regarding a failure in an application program module. The failure may be a crash, a set-up failure or an assert.
In one aspect of the invention, for a crash, a name of an executable module where the crash occurred in the application program module, a version number of the executable module, a name of a module containing an instruction causing the crash, a version number of the module and an offset into the module with the crashing instruction are determined. This bucket information is then transmitted to a repository for storage in a database. The database may be examined to determine fixes for the bug that caused the crash.
In another aspect, for a set-up failure, a product code of the application program module that was being installed at the time of the set-up failure is determined. A product version of the application program module that was being installed at the time of the set-up failure is determined. The final set-up action that was performed during set-up before the failure is determined. An internal error number assigned to the failure that occurred is determined. ErrorFields 12, and 3 are determined. These error fields are defined by the particular error number. The product code, product version, final set-up action, error number and error fields define a bucket that may be sent to a repository for storage.
These and other features, advantages, and aspects of the present invention may be more clearly understood and appreciated from a review of the following detailed description of the disclosed embodiments and by reference to the appended drawings and claims.